Communication interface between pc&#39;s and auxiliary platforms in an intelligent network

ABSTRACT

This invention relates to user access device to intelligent services of an intelligent network (IN) comprising a service control point ( 2 ) that communicates with at least one group of physical entities ( 4, 6, 8 ) designed to provide at least one initial service element, and with several auxiliary platforms ( 10   i ) designed to provide users with additional service elements for completing the initial service element.  
     According to the invention, the device also comprises a communication interface ( 12 ) that allows an auxiliary platform ( 10   i ) to send the service control point ( 2 ) service element execution queries in real time, and receive the data for executing these additional services from this service control point ( 2 ) as a response.

[0001] This invention relates to a user access device to IN (intelligentnetwork) services and method comprising a service control point thatcommunicates with at least one group of physical entities designed toensure at least one initial service element, and with several auxiliaryplatforms designed to provide the user with additional service elementsfor completing the initial service element.

[0002] Intelligent networks comply with ITU-T recommendations Q.120x,Q121x, Q.122x and Q.123x and stem from the need to provide access toservices that invoke several applications such as voice, electronicmessaging, file transfer, or transactional processing, etc. services, bycentralising their control. Generally, applications are linked toperform a new service by using the architecture implemented in theapplication layer.

[0003] To allow the existing infrastructure in the communication networkto take on the functionalities of the new service, intelligent networksimplement the following standardised functional entities:

[0004] Service Control Function (SCF), whose corresponding physicalentity in the IN network architecture is a Service Control Point (SCP);

[0005] Service Switching Function (SSF), whose corresponding physicalentity is a Service Switching Point (SSP);

[0006] Service Data Function (SDF), whose corresponding physical entityis a Service Data Point (SDP);

[0007] Specialised Resource Function (SRF), whose corresponding physicalentity is an Intelligent Peripheral (IP).

[0008] Service Management Function (SMF), whose corresponding physicalentity is a Service Management Point (SMP).

[0009] In known IN services, the Service Control Function (SCF) supportsa user interface that implements an important part of the ServiceControl Function (SCF). This user interface ensures:

[0010] all the actions implemented by the service to inform users andprompt them to make their choices;

[0011] all the actions of the device that collect the user's choices;

[0012] release and concatenation of these actions such as invitationsand collection of choices;

[0013] concatenation of these actions with other service call processingactions.

[0014]FIG. 1 provides a diagram illustrating a known device foraccessing an NI service in which a service control point 2 communicateswith a service database, an access switch 6 to which the user telephoneline 7 is connected, a service management point 8, and several auxiliaryplatforms 10 _(i). An auxiliary platform 10 _(i) can be either anintelligent peripheral containing specific resources to allow adaptingservice controls on user demand, or a value-added server such as amessaging server, a service management point informing users of theirconsumption or any other type of server. The auxiliary platform can alsobe another service control point when two intelligent networks areconnected within the same call.

[0015] The resources of an intelligent peripheral can be announcers,speech synthesis equipment, speech recognition equipment, equipmentrequired for videoconferencing, tone generators, speech synthesis testsor protocol converters, etc.

[0016] When an auxiliary platform is an intelligent peripheral, twosituations may arise:

[0017] the service control point 2 manages all the service controlfunctions, for example, in a card service in which the service controlpoint 2 manages the launching of the card and code digit input phase,the launching of the authentication based on the digits entered, theverification of the card's rights, the launching of the requested numberentered, the verification of the rights that the card has to call thisnumber, the number call, as well as the concatenation with the nextcall.

[0018] the service control point 2 assigns certain subtasks to theintelligent peripheral, in lesser or greater numbers depending onwhether the intelligent peripheral is used in “step” or “script” mode.

[0019] In “step” mode, the intelligent peripheral is completelycontrolled by the service control point 2 that, during an initialcommand, instructs it to, for example, transmit a specific message to auser, and in another command, collect the user's choice.

[0020] In “script” mode, the intelligent peripheral has some latitude inconcatenating certain user interface subtasks such as the transmissionof an invitation message, collection of the user's choice andtransmission of another invitation message.

[0021] In both cases, the intelligent peripheral performs the requestedtask and recognises the service control point 2 without everself-concatenating the tasks it has been assigned. Moreover, theintelligent peripheral never concatenates user interface phases withother IN service phases. It is only used as an additional servicecontrol module 2 resource to ensure specialised functions, which areoften voice functions.

[0022] This centralization of the service control function (SCF) at theservice control point 2 does prevent the user interface from developingquickly. Indeed, the part of the user interface functionalities thatresides in the service control point 2 and used to configure, launch,and concatenate the tasks requested from the intelligent peripheral isoften embedded in a monolithic software application that covers all callprocessing. Therefore, any modification in user interface functionalityrequires modification of the service control module 2, at the level ofdata transmitted to the intelligent peripheral for executing the tasksit has been assigned, at the phase concatenation level, and on theintelligent peripheral in order to modify the subtasks and the type ofdata to be received from the service control module 2. This results in alack of flexibility in the development of the service because of theneed to perform non-regression tests as soon as a modification is madeon the service control point 2 software application. This prolongs thedevelopment/validation cycles.

[0023] Furthermore, when an auxiliary platform is a value-added server,there are no ITU-T recommendations or international standards governingexchanges. Moreover, operators have their own specifications that aresometimes slightly different from the standards.

[0024] When an auxiliary platform is a second service control point,there is no data exchange mode between these two service control pointsmanaging various services in two different intelligent networks.

[0025] This leads to a heterogeneity of communication interfaces betweenthe various auxiliary platforms and the service control module, whichresults in the need to store the service control point 2 of severaldifferent software applications in the random access memory, making theservice control point more complex and hindering service development.

[0026] The object of the invention is to provide new distribution ofservice control functions between the service control point and theauxiliary platforms in which the IN service user interface istransferred over to external platforms, which are specialised machinesthat can concatenate all the user interface stages, while not beinginterface tributaries with other equipment in the intelligent network.

[0027] Another goal of the invention is to eliminate the heterogeneityof interfaces between the service control module and the variousauxiliary platforms in order to allow services to evolve withoutmodifying the functions dedicated to the service control point.

[0028] According to the invention, the access device comprises acommunication interface that allows an auxiliary platform to send theservice control point service element execution queries in real time,and receive data that allows executing additional services from thisservice control point, as a response.

[0029] According to the invention, for a given service, the queries sentto the service control point have the same format, regardless of thetransmitting auxiliary platform, and the data sent by the servicecontrol point to the transmitting auxiliary platform have the sameformat.

[0030] According to the invention, the first service element that theauxiliary platform requests from the service control point is a userauthentication, access authorisation or a number call.

[0031] Thanks to the invention, the service control point SCP isrelieved from managing additional services, which is transferred over tothe auxiliary platforms. Therefore, the development of a new servicevariant does not involve modifying the service control point if thisdevelopment only applies to the user interface or additional services.Developments of service variants are therefore easier, since they aremore common on external platforms than on the service control point.

[0032] Moreover, the cycle times of service developments are reduced inthe sense that it is no longer necessary to perform non-regression testson the aspects, network, control, charging, etc. of the NI servicebecause they remain under the control of the SCP, and only the auxiliaryplatforms evolve with the user interface or the additional services.

[0033] Furthermore, the genericity of the communication interfacequeries according to the invention allow taking into account the varioustypes of auxiliary platform and, in particular, to solve the problem ofinteroperation of the intelligent network services when the auxiliaryplatform is a SCP of another NI.

[0034] The user access procedure to the NI service includes thefollowing stages:

[0035] real-time sending by the auxiliary platform to the servicecontrol point of at least one execution query of a first service elementdedicated to the service control;

[0036] sending by the service control point to the transmittingauxiliary platform of the data query that allows the latter to executeadditional services.

[0037] Other characteristics and benefits of the invention will beprovided in the description to follow, to be taken as a non-limitingexample and referencing the attached figures in which:

[0038]FIG. 1 provides a diagram partially illustrating the links betweenfunctional entities of a prior art intelligent network:

[0039]FIG. 2 provides a diagram partially illustrating the links betweenfunctional entities of an intelligent network according to theinvention.

[0040]FIG. 3 provides a diagram illustrating an initial mode ofcommunication between an auxiliary platform and a service control pointaccording to the invention;

[0041]FIG. 4 provides a diagram illustrating a second mode ofcommunication between an auxiliary platform and a service control pointaccording to the invention;

[0042] FIGS. 5 to 12 and 15 and 16 represent tables that illustrate theformats of the data exchanged between a service control point and anauxiliary platform in a specific application according to the invention.

[0043]FIGS. 13 and 14 illustrate the concatenation of two servicesimplementing the procedure according to the invention.

[0044]FIG. 1 described above, illustrates a device for accessing an INservice in which a service control point 2 communicates with a servicedatabase, an access switch 6 to which a user telephone line 7 isconnected, a service management point 8 and several auxiliary platforms10 _(i). An auxiliary platform indiscriminately designs an intelligentperipheral 10 ₁, 10 ₂, a value-added server 10 ₃ such as avoice-messaging server, a voice interactive server or a second INservice control point.

[0045] According to the essential characteristic of the invention,illustrated by FIG. 2, a communication interface 12, fitted betweenservice control point 2 and the auxiliary platforms 10 _(i), allows anauxiliary platform 10 _(i) to send the service control point 2 aninitial service element execution query in real time. This initialservice element can be user authentication, access authorisation or thenumber call. The service control point 2 executes this initial serviceelement and resends data in response to the query sent to allow thetransmitting auxiliary platform 10 _(i) to execute its dedicatedadditional services. The auxiliary platform then transmits other queriesto the SCP so that the latter can execute its dedicated serviceelements.

[0046] Query transmission can be done through a direct link, such as theone illustrated in FIG. 3, via TCP/IP (Transmission communicationprotocol/Internet protocol) or the SS7 (Signalling System N° 7)protocol, or through a relay link, such as the one illustrated in FIG.4, using the same path as the related speech circuit. In this case,because queries are transported in the speech path signalling, theplatform can easily create the link between the application queries andvoice communication. This is not the case with a direct link becauseboth links are initialised, the first link to carry the queries over theIP (Internet Protocol) network or over the SS7 network, and the secondlink to carry the speech signals. Therefore, it is necessary for theauxiliary platform 10 _(i) and the service control point 2 tosynchronise the two links. The mechanism used for this synchronizationis based on the use of a reference and is illustrated in FIG. 3 in thecase of an IP link. This mechanism is the same for a direct link via theSS7 protocol.

[0047] With reference to FIG. 3, the sequencing of the TCP/IP link usingthe reference is as follows:

[0048] I The service control point 2 launches a voice call via theaccess switch 6 to a platform 10 _(i). An “R” reference is placed in thesignalling that sets up this call, for example, National ISDN User Part(ISUP) signalling. This “R” reference comprises the reference for thefuture exchange session for auxiliary platform/service control point 2application queries.

[0049] II The voice call arrives at the platform that reads in thespeech path signalling the “R” reference of the session of queriesexchanged with the service control point 2.

[0050] III The platform transmits an initialization query containing the“R” reference over the TCP/IP link.

[0051] IV Using the “R” reference, the service control point 2 createsthe link between the call being sent to the platform 10 _(i) over thespeech path and the initialization query, and responds to theinitialization query by transmitting the response to this initializationquery to the platform 10 _(i) over the TCP/IP link; this response alsocontains the “R” reference so that the platform 10 _(i) can identify thevoice call to which this response is related.

[0052] V The platform 10 _(i) transmits other application queries overthe TCP/IP link according to the service that it initialises, forexample, an authentication request.

[0053] Whatever query is transmitted over the TCP/IP link, it containsthe “R” reference; the response transmitted by the SCP over the TCP/IPlink also contains this “R” reference. Also, during the entire queryexchange session over the TCP/IP link, the platform 10 _(i) and theservice control point 2 can join the query session to the voice call.

[0054] In the case of a relay link, the sequencing is the same as in thecase of a link over TCP/IP, except that the reference is not usefulbecause network signalling naturally creates the link between thesequeries and the speech path on which the queries are based. The twostreams in fact follow the same channel.

[0055] Sequences I to V correspond to their equivalents in TCP/IP modeillustrated in FIG. 3.

[0056] To better highlight the parameters exchanged between an auxiliaryplatform 10 _(i) and the service control point 2, a specific applicationwill be described in which the intelligent service is a Cardtelecommunications service. The service control point 2 will bedesignated in the next phase using the SCP-Card expression, andauxiliary platforms 10 _(i) will be external servers designated by theSE expression.

[0057] In terms of operation, the SCP-Card responds to theinitialization query of the dialogue between the Card Application andthe application that resides in the auxiliary platform 10 _(i) bysending an initialisation request with the following structure:

[0058] R-Initialisation_PCS={Contexte_A, Contexte_B}

[0059] Contexte_A={CtxDial, CtxSrv, CtxDdr, CtxCarte, CtxInfo}

[0060] Contexte_B={BufferSE}

[0061]FIG. 5 includes a table that explains the CtxDial parameterrepresenting the data that identifies the dialogue.

[0062] The Version field allows simultaneously managing two versions ofthe query description: a new version N and the previous version N-1. Itindicates to the auxiliary platform 10 _(i) the version in which thequeries will be transmitted up to the end of the SCP-SE dialogue.

[0063] The service number in the application will be taken from the IdSvservice identifier by the auxiliary platform 10 _(i) application, ifrequired.

[0064] If the SCP-Card connects to an auxiliary platform 10 _(i) toinitiate a voice dialogue over this auxiliary platform 10 _(i), theCodeReprise field is absent.

[0065] If the SCP-Card reconnects to an auxiliary platform 10 _(i) toresume and track a voice dialogue, the EntréeDialSE field increases invalue as follows:

[0066] EntréeDialSE=0 if the auxiliary platform 10 _(i) is recontactedafter the calling party enters “*” during the call return. This is nottaken into account for services using voice recognition.

[0067] EntréeDialSE=1 if the auxiliary platform 10 _(i) is recontactedafter a no answer by the called party.

[0068] EntréeDialSE=2 if the auxiliary platform 10 _(i) is recontactedafter the called party hangs up (call concatenation).

[0069]FIG. 6 includes a table that explains the CtxSrv parameter thatrepresents the service data over the Card call.

[0070] The NEnch parameter indicates the number of call concatenationsthe calling party performs on the SCP-Card before connecting to theauxiliary platform 10 _(i) or between connections to different auxiliaryplatforms 10 _(i). The number of call concatenations is accumulated fromthe start of the Card call.

[0071] NRDeMax is the maximum number of called party call renewalsauthorised by the SCP-Card.

[0072]FIG. 7 includes a table that explains the CtxDdr parameter thatrepresents the data over a calling line and the calling party.

[0073] The values for TypeTerm, CgPCateg, NatDdr, NResDdr, and PrefFDincrease starting from the Provide at the beginning of the Card call andby analyzing the calling party number.

[0074]FIG. 8 includes a table that illustrates the CtxCarte parameterthat represents part of the data sent to the authentication centre ACand its response.

[0075] These parameters can only be provided when the code-card inputand the Authentication Centre query are performed by the SCP-Card beforeconnecting to the auxiliary platform 10 _(i).

[0076] The value of Ipas increases upon inputting the subscriber cardnumber or the response sent by the authentication centre AC in the caseof fast authentication.

[0077] The remaining fields can be completed using the values providedby the Authentication Centre (AC).

[0078] Note that the Code field representing the subscriber confidentialcode will only be transmitted to the auxiliary platform 10 _(i) underexceptional circumstances for example, in an auxiliary platform 10 _(i)application that allows subscribers to modify their confidential code.

[0079]FIG. 9 provides a table explaining the CtxInfo parameter thatrepresents additional data.

[0080] The NumDdé parameter is useful if the auxiliary platform 10 _(i)is a voice messaging system that offers differed call service.

[0081] The TransMV field is also designed for a voice messaging typeauxiliary platform and allows specifying the cause of the retransmissiontoward this messaging system if needed: no answer, busy, congestion,during a called party call.

[0082] MaxCom represents the maximum authorised communication duration,calculated in seconds by the Rate Server (RS) that resides in theservice management point. This field can only be completed if therequested number has been input and a query of the service managementpoint 8 has been performed by the PCS-Card before the connection requestto the auxiliary platform 10 _(i).

[0083] The RefAppel field is a sequence of 15 octets that breaks down asfollows:

[0084] octets 1 to 5: DATE field=start of call processing, DCB-coded inthe following format: MMDDhhmmss.

[0085] octets 6 to 7: CPAYS fields=SCP country code (DCB-coded).

[0086] octets 8 to 11: IDPCS field=SCP identifier (SGTQS code),ASCII-coded without parity.

[0087] octets 12 to 15: REFC field=circular reference,hexadecimal-coded.

[0088] The maximum length of the CaracServ field is 16 octets:

[0089] octet 1: CARSRV field=characteristic parameters of theIntelligent Network services. It is coded on an octet in the followingmanner (where A is the low-order bit):

[0090] A=1, rerouting not allowed (i.e., Audiotel or Toll Free). ElseA=0.

[0091] B=1, Call Completion not allowed (i.e., 12). Else B=0.

[0092] C=1, AOCD (requested telephone charge). Else C=0.

[0093] D=1, parsing is not allowed without transmitting the responsesignal. Else D=0.

[0094] E, F, G, H on standby and set to =0.

[0095] octet 2: SVTR field=crossed services, value increase to 0Fh.

[0096] The Contexte_B field is used at the service control point to passthe data previously transmitted by the auxiliary platform.

[0097] This field is useful when the service control point and theauxiliary platform recover a dialogue after it has been interrupted, forexample, during call concatenation. The service control point does notinterpret the field that contains the data belonging to the auxiliaryplatform, as does the indication of a recovery point in its servicescript. Note that when recovering dialogue for call concatenation, theauxiliary platform can be the same type of platform as the one usedpreviously, but must be a different sample.

[0098] Each time that the SCP-Card wants to completely release theconnection to the auxiliary platform 10 _(i), it first transmits aRelease SCP query to the auxiliary platform. The purpose of this queryit to allow the auxiliary platform 10 _(i) to release its own resourcesand be able to transmit, in this particular case, a notification to thecalling party before the SCP-Card cuts off the link. Therefore, theSCP-Card will always wait for the response to the Release SCP to theauxiliary platform 10 _(i), or possibly, the timeout of no-answer tothis query, before transmitting the FREE operation on the auxiliaryplatform link.

[0099]FIG. 10 indicates a table illustrating the card of parameters sentto the auxiliary platform 10 _(i) in a Release SCP query to theauxiliary platform.

[0100] For some end-of-dialogues causes, the auxiliary platform 10 _(i)will not be able to transmit voice messages to the calling party. Forexample, if the Release SCP query to the auxiliary platform is sentafter a number call request and hang-up request, the SCP-Card mustimmediately cut the calling party-auxiliary platform 10 _(i) voicecircuit (SPLIT) to establish the calling party-called party voicecircuit (JOIN). The list of CFDial codes therefore distinguishes thesituations where the auxiliary platform 10 _(i) may or may not have avoice link with the calling party until it sends its response:

[0101] CFDial=0 to 49: the auxiliary platform 10 _(i) does not have avoice link with the calling party.

[0102] CFDial=50 to 255: the auxiliary platform 10 _(i) has a voice linkwith the calling party up to the moment it transmits its response to theRelease SCP query to the auxiliary platform; it will therefore be ableto transmit a message to the calling party.

[0103] The CFDial codes≧100 designate the errors detected by the CardApplication Driver and sent to the application so that the latter canend the dialogue between the SCP-Card and the auxiliary platform 10 _(i)using a Release SCS to the auxiliary platform.

[0104] The SCP-Card continues its processing according to the cause ofthe CFDial dialogue end:

[0105] If CFDial=0: processing standby for called party response.

[0106] If CFDial=1: processing the communication follow-up with thecalled party.

[0107] Receipt of the auxiliary platform response awaited and processedin the corresponding statuses.

[0108] For the other CFDial values, the SCP-Card awaits acknowledgementby the auxiliary platform 10 _(i) before launching a call end process.If the auxiliary platform 10 _(i) acknowledgement is not received, theSCP-Card also launches a call end process. In any case, receipt of theauxiliary platform 10 _(i) response allows the SCP-Card to release thelink to the auxiliary platform 10 _(i) and increase the value of thecommunication part of the service it offers, the closing, if needed, andthe sending of a communication detail.

[0109] The SCP-Card transmission of an initialisation response isfollowed by a series of application queries that the auxiliary platformtransmits to the SCP-Card. These are described below.

[0110] Of course, application processing of the SCP-Card upon receipt ofthe queries from the auxiliary platform are given for informationpurposes for the Card Application using the control interface accordingto the invention.

[0111] If the query is an authentication request, an auxiliary platform10 _(i) requests the authentication of a card-code from the cardAuthentication Centre via the SCP-Card. The acknowledgement of thecard-code digits is completely dedicated to the auxiliary platform 10_(i) that performs the following tasks:

[0112] invitation to dial or say the numbers;

[0113] repetitions in case the user has not input or said the numbers:

[0114] possible format or length controls, etc.

[0115] Note that to query another Card Application AuthenticationCentre, this request might need to be developed or specifications ofother authentication queries might be needed because the types of dataresiding in these centres may vary from one application to another.

[0116]FIG. 11 represents a table that explains the parameters receivedfrom the auxiliary platform 10 _(i) for this authentication request.

[0117] Several types of authentication are possible on the SCP-Card. TheSCP-Card identifies these types of authentication using the card-codesequence format input by the user:

[0118] Format 1: low-grade authentication: “i digits” (i=9 card digits+4code digits).

[0119] Format 2: low-grade authentication after the set passes to DTMF:“#+i” or “*+i digits” (i=13).

[0120] Format 3: fast authentication: “j digits” (j=4 digits of the codeonly).

[0121] Format 4: fast authentication after the set passes to DTMF: “#+jdigits” or “*+j digits” (j=4).

[0122] Format 5: high-grade authentication: “##+k digits” or “+#+kdigits” (k=19 maximum).

[0123] The auxiliary platforms 10 _(i) have two possibilities:

[0124] the auxiliary platform 10 _(i) does not know the low-grade,high-grade, or fast authentication notions, in which case, it sends theSCP-Card a unique card-code sequence corresponding to the rawinformation input or said by the user and concatenated into a singlesequence (Saisie_CC), even if the acquisition is performed in severalstages on the auxiliary platform 10 _(i). The TypAuth field is thereforeabsent from the query.

[0125] the auxiliary platform 10 _(i) is aware of the four types ofauthentication and is able to offer them to the user or identify themwhen the user inputs/says them, in which case, the auxiliary platform 10_(i) sends the SCP-Card the concatenated card number and the code number(Saisi_CC), without the “+”, “#”, “##”, or “*#” identifiers, but withthe type of authentication recognised by the auxiliary platform 10 _(i)TypAuth:

[0126] TypAuth=0: low-grade authentication (format 1 or 2).

[0127] TypAuth=1: fast authentication (format 3 or 4).

[0128] TypAuth=2: high-grade authentication (format 5).

[0129] In both cases, the SCP-Card does not receive the end delimiter ifthe input is received in DTMF mode on the auxiliary platform 10 _(i).

[0130]FIG. 12 represents a table illustrating the parameters returned bythe SCP-Card in response to this authentication request.

[0131] The CodeRetour parameter is common to all responses of theauxiliary platform queries to the SCP-Card. It comprises:

[0132] a Numéro field whose value is systematically 0 if the query wasprocessed correctly, and a positive value associated to the error found,otherwise.

[0133] an Annonce field: contains the OSV announcement number that theSCP would use if an error occurs, corresponding to the mode without acontrol interface. This field is optional.

[0134] a FinAppel field: set to NO, it may allow the auxiliary platform10 _(i) to continue its voice dialogue if the error does not block itsprocessing, and to repeat the query or concatenate a new one (example:the authentication centre CRES indicates that the code does not match).When set to YES, it indicates to the auxiliary platform that theSCP-Card cannot continue the call. The auxiliary platform 10 _(i) mustinform the user of the error and send a “Release auxiliary platform toSCP” query (example: no answer from authentication centre withoutaccepting the reject exception).

[0135] The Ipas card number is systematically retransmitted to theauxiliary platform 10 _(i), whether it has performed the Saisi_CCsequence analysis or not.

[0136] The Code (user confidential code) field is only transmitted tothe auxiliary platform under exceptional circumstances (example:auxiliary platform 10 _(i) application that allows a user to modify hisor her confidential code).

[0137] The Ilas, Tsc, Cco, Catc, Scom, Imi, and Cptx parameters are acopy of the parameters provided by the Authentication Centre. If theCard is not limited, Cptx and Imi will be absent.

[0138] NbAuthMax and CptAuth allow the auxiliary platform 10 _(i) tomodulate its card-code input announcements (first, nth, or lastannouncement), or to offer help after a specific failure rate.

[0139] Enchaînement_autorisé, Appel_urgent_Sans_crédit andException_rejet are derived by the SCP-Card from the type ofauthentication centre (AC) response and the call context. They aretransmitted to the auxiliary platform 10 _(i) to direct the processingof its voice script.

[0140] When a query sent by the auxiliary platform 10 _(i) is anauthorisation and service value increase request, the service term ofthe query designates not only an auxiliary platform 10 _(i) internalservice number, but also a requested number joined by the auxiliaryplatform 10 _(i), as well as a number requested and joined by the SCP.

[0141] The authorization and service value increase request is sent bythe auxiliary platform 10 _(i) to increase the value of the previouslyqueried service cost, authorise the user to consult the selectedsubsequent service and, if needed, open a new communication detail CDfor this service.

[0142] Query processing by the SCP-Card comprises three stages:

[0143] Value increase processing of the previous communication(calculation of the duration, cost, CD transmission, decrease ofpossible limit of the card).

[0144] Authorisation processing on the subsequent service (numberanalysis, possible authorization/translation of a CD transmission, SdTcredit query).

[0145] Rate Application processing of the subsequent service (opening ofits CD).

[0146] The input parameters of the query (Valo, Aut, and ApTar) willindicate the processing performed by the SCP-Card before sending theCodeRetour.

[0147]FIG. 13 illustrates an example in which a subscriber concatenatestwo internal SV1 and Sv2 services over a single free access auxiliaryplatform 10 _(i) that includes the following stages:

[0148] a) Connection to the free access auxiliary platform 10 _(i). Nocommunication details (CD) are opened in the case of free access;

[0149] b) (Valo, Aut, ApTar)=(0, 1, 1). Authorisation request on service1 and opening of communication detail CD1.

[0150] c) (Valo, Aut, ApTar)=(1, 0, 0). Value increase of communicationdetail CD1.

[0151] d) (Valo, Aut, ApTar)=(0, 1, 1). Authorisation request on service2 and opening of communication detail (CD2).

[0152] e) (Valo, Aut, ApTar)=(1, 0, 0). Value increase of communicationdetail CD2.

[0153]FIG. 14 illustrates an example in which a subscriber concatenatestwo internal SV1 and Sv2 services over a single paying access auxiliaryplatform 10 _(i) that includes the following stages:

[0154] a) When connecting to the auxiliary platform 10 _(i), the SCPopens a communication detail DC0. The connection time to the auxiliaryplatform 10 _(i) is counted from the moment the auxiliary platform 10_(i) is off-hook.

[0155] b) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communicationdetail DC0, authorisation request on service 1, and opening of CD1.

[0156] c) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communicationdetail DC1, authorisation request for the return to the general menu(essentially to determine the credit remaining of a limited card afterconsulting service 1), and opening of communication detail CD2.

[0157] d) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communicationdetail DC2, authorisation request on service 2, and opening of CD3.

[0158] e) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communicationdetail DC3, authorisation request for the return to the general menu,and opening of communication detail CD4.

[0159] f) (Valo, Aut, ApTar)=(1, 0, 0). Value increase of communicationdetail DC4.

[0160] Note that the time reference is always based on the SCP-Cardclock. The start and end times of service queries must be saved by theSCP. The auxiliary platform 10 _(i) must therefore formulate itsauthorisation and service value increase query according to the natureof the service (auxiliary platform 10 _(i) internal service, call joinedby the auxiliary platform 10 _(i), or call joined by the SCP-Card) andindicate to the SCP when the time should be obtained. The inputparameters involved are the triplet (Valo, Aut, ApTar) and theApplication_tarif_immédiate indicator:

[0161] In the case of an auxiliary platform 10 _(i) internal service(specific voice menu of the auxiliary platform 10 _(i)), the auxiliaryplatform 10 _(i) must increase the value of its authorisation andservice value increase request with (Valo, Aut, ApTar)=(x, 1, 1) andApplication_tarif_immédiate=YES. The SCP saves the start time of theservice query just after the communication detail CD is opened. The endof the service query is indicated by a second query with (Valo, Aut,ApTar)=(1,x, x,).

[0162] In the case where the service is a call joined by the auxiliaryplatform 10 _(i), the auxiliary platform 10 _(i) must increase the valueof an initial authorisation and service value increase request with(Valo, Aut, ApTar)=(x,1, 0). The auxiliary platform 10 _(i) joins thecall. When the called party goes off-hook, it sends the SCP-Card asecond authorisation and service value increase query with (Valo, Aut,ApTar)=(0, 0, 1) and the Application_tarif_immédiate=YES. When the userhangs up, the auxiliary platform 10 _(i) sends a third query with (Valo,Aut, ApTar)=(1, x, x,) to indicate the end of the conversation to theSCP-Card.

[0163] In the case where the service is a call joined by the SCP-Card:the auxiliary platform 10 _(i) must increase the value of an initialauthorisation and service value increase request with (Valo, Aut,ApTar)=(x, 1, 0). The SCP-Card recovers the conversation start and endtimes on the ANM/CON and REL signals without indication from theauxiliary platform 10 _(i).

[0164]FIG. 15 represents a table that illustrates the parametersreceived from the auxiliary platform 10 _(i) for this authorisation andservice value increase query.

[0165] The ModeTax1 field is increased in value by the auxiliaryplatform 10 _(i) according to the ModeTax2 parameter value of theprevious service value increase.

[0166] By way of example, a subscriber with a limited card chooses toquery a paying service offered by the auxiliary platform 10 _(i). Thelatter sends the SCP-Card an authorisation and service value increaserequest with (Valo, Aut, ApTar)=(absent, present, present). The SCP-Cardperforms an SdT inquiry during the query processing to find the chargemethod applied to the service and communicates it to the auxiliaryplatform 10 _(i) in its response (ModeTax2). The auxiliary platform 10_(i) might not use this value during processing but it saves it untilthe user finishes querying the service. Once the query is completed, theauxiliary platform 10 _(i) sends the SCP-Card an authorisation andservice value increase request configured with (Valo, Aut,ApTar)=(present, absent, absent) by recalling the type of chargesapplied to the service in the ModeTax1 field. Thus, there is noconfusion for the SCP-Card regarding the service value increase mode.

[0167] ModeTax1 is equal to 0 (normal cost), 1 (inclusive cost), 2 (tollfree), or 3 (ITX charges).

[0168] ModeTax1 is absent if Valo=0.

[0169] The Numéro field accepts all the available formats: national,short or long distance unlocalised, special, international, abbreviated,or private.

[0170] The AnnCrédit=1 field allows the auxiliary platform 10 _(i) torequest that the credit announcement be exceptionally transmitted by theSCP-Card in Voice Server Equipment (VSE) mode.

[0171] The Numéro and AnnCrédit fields are absent when Aut is absent.

[0172] The Application_tarif_immédiate field is absent when ApTar isabsent.

[0173] In the case where the auxiliary platform query to a CARD-Card isa number call request, it also takes into account the case of a routingrequest to an operator set after an input error occurs or when the userfails to input anything. The auxiliary platform 10 _(i) may precede thenumber call request with an authorisation service value increase queryon this number. For example:

[0174] for an ordinary requested number, the auxiliary platform 10 _(i)would have performed an authorisation/service value increase request onthe called party number in order to verify the minimum value that thenumber can have during routing.

[0175] for an operator set access number: the numbers are alreadyavailable in the operating data of the SCP-Card in network format. Theycan be routed and used in the CREATE operation without the SCP-Cardneeding additional analysis.

[0176] When the call return is distributed, the auxiliary platform 10_(i) is completely released. Reconnection to the auxiliary platform 10_(i) will be performed in the following three circumstances:

[0177] when the calling party wishes to interrupt the call currentlybeing established;

[0178] when a timeout occurs due to a no answer from the called party;

[0179] or possibly, after the conversation to offer call concatenation.

[0180] The SCP-Card will indicate to the auxiliary platform 10 _(i) thatthe recovery point of the voice script is “enter asterisk,” “no answerfrom called party,” or “call concatenation” using the value indicated inthe Contexte_A entréeDialSE field in the initialisation response.

[0181]FIG. 16 represents a table that illustrates the parametersreceived from the auxiliary platform 10 _(i).

[0182] The NumDdé field is optional and operates as follows:

[0183] NumDdé is absent if the auxiliary platform 10 _(i) has previouslytransmitted an authorisation/service value increase request. TheSCP-Card has already saved the called party network number (in theCREATE operation format) and its nature (national, international, etc.)after having analysed the Numéro field of the authorisation/servicevalue increase request.

[0184] NumDdé is absent if the auxiliary platform 10 _(i) performs acall request to an operator set. The Appel_opérateur field is set to YESin this case.

[0185] NumDdé=0 is directly a national network number that can be routedif the auxiliary platform 10 _(i) wishes to establish communication to arequested number without previous authorisation/service value increase.

[0186] The RappelSE=0 field indicates to the SCP-Card that it mustrecontact the auxiliary platform 10 _(i) after the called party has hungup. If the RappelSE field is set to 1, the auxiliary platform is notrecalled and the possible call concatenations will be offered in thewithout control interfaces mode.

[0187] If the RappelSE field is set to 2, the auxiliary platform 10 _(i)is not recalled and no call concatenation is offered in the withoutcontrol interfaces mode.

[0188] Note that the CARD-Card does not implement any call concatenationwithout control interfaces (PCS/OSV mode) if the nature of the auxiliaryplatform 10 _(i) is that it can be called by the SCP in controlinterface mode when the SCP receives the Provide-Instructions command,because, in this case, the auxiliary platform 10 _(i) carries the entireuser interface of the service. In this example, RappelSE should never beequal to 1.

[0189] The Appel_opérateur field allows the SCP-Card to perform certainadditional processes specific to the retransmission to the operator:network operator number search in the operating tables, transmission ofan announcement to the operator once off-hook, etc.

[0190] Note that the Contexte_B field containing information that isuseful to the auxiliary platform 10 _(i) for recovering its voice scriptshould be systematically transmitted to the SCP-Card with the numbercall query because, on each call, the auxiliary platform 10 _(i) cannotknow if there will be “input asterisk” or “no answer from called party”type recovery points.

[0191] On the other hand, the auxiliary platform 10 _(i) will stillindicate to the SCP if it wants to be recontacted or not after asuccessful calling party-called party conversation by increasing thevalue of the input parameter RappelSE field of a number call query.

1. User access device to intelligent services of an intelligent network(IN) comprising a service control point (2) that communicates with atleast one group of physical entities (4, 6, 8) designed to provide atleast one initial service element, and with several auxiliary platforms(10 _(i)) designed to provide the user with the additional serviceelements that complete the initial service element, device characterisedin that it also comprises a communication interface (12) that allows anauxiliary platform (10 _(i)) to send the service control point (2)service element execution queries in real time, and receive the datathat allows executing these additional services from this servicecontrol point (2) as a response.
 2. Device according to claim 1,characterised in that, for a given service, the queries sent to theservice control point (2) have the same format regardless of thetransmitting auxiliary platform (10 _(i)), and the data sent by theservice control point (2) to the auxiliary platform (10 _(i)) have thesame format.
 3. Device according to claim 1, characterised in that theinitial service element execution query transmitted by the auxiliaryplatform is either a user authentication request, an accessauthorisation request, or a number call request.
 4. Device according toclaim 2, characterised in that the queries are sent to the servicecontrol point (2) in direct mode according to the TCP/IP protocol. 5.Device according to claim 2, characterised in that the queries are sentto the service control point (2) in direct mode according to the SS7protocol.
 6. Device according to claim 2, characterised in that thequeries are sent to the service control point (2) in relay mode throughthe same channel that is used for voice signalling.
 7. Device accordingto claim 2, characterised in that the auxiliary platform (10 _(i)) is anintelligent peripheral.
 8. Device according to claim 2, characterised inthat the auxiliary platform (10 _(i)) is a value-added server.
 9. Deviceaccording to claim 2, characterised in that the auxiliary platform (10_(i)) is a service control point of a second intelligent network. 10.Device according to claim 1, characterised in that the physical entitygroup comprises at least one access switch (6), and at least one servicemanagement point (8) or equivalent function residing in the servicecontrol point (2).
 11. Device according to claim 7, characterised inthat the intelligent peripheral is a user interaction platform thatensures the following additional service: a—user information when usingthe service; b—user invitation to determine user choices; c—collectionof user choices; d—activation and concatenation of actions (a), (b), and(c): e—concatenation of actions (a), (b), and (c) with other actionsthat do not stem from the platform but that are outsourced to theservice control point (2) or to the physical entities (4, 6, 8) via theservice control point (2), through service execution queries transmittedto the service control point (2).
 12. User access method to the INservices of an intelligent network comprising a service control point(2) that communicates with at least one group of physical entities (4,6, 8) designed to provide at least one initial service element, andseveral auxiliary platforms (10 _(i)) designed to provide the user withadditional elements that complete the initial service element, saidprocedure being characterised in that it comprises the following stages:real-time sending by the auxiliary platform (10 _(i)) to the servicecontrol point (2) of at least one execution query of service elementsdedicated to the service control point (2); sending by the servicecontrol point (2) to said transmitting auxiliary platform (10 _(i)) ofthe data that allows the latter to execute additional services. 13.Procedure according to claim 12, characterised in that, for a givenservice, the queries sent to the service control point (2) have the sameformat, regardless of the transmitting auxiliary platform (10 _(i)), andthe data sent by the service control point (2) to said transmittingauxiliary platform (10 _(i)) has the same format.
 14. Method accordingto claim 12, characterised in that the first service element that can beexecuted by the service control point (2) and requested by the auxiliaryplatform (10 _(i)) at the service control point using a query, compriseseither a user authentication stage, a service access authorisationstage, or a number call stage.